Various classes of block diagrams describe computations that can be performed on application specific computational hardware, such as a computer, microcontroller, FPGA, and custom hardware. Classes of such block diagrams include time-based block diagrams such as those found within Simulink® from the MathWorks, Inc. of Natick Mass., state-based and flow diagrams such as those found within Stateflow® from the MathWorks, Inc. and data-flow diagrams. A common characteristic among these various forms of block diagrams is that they define semantics on how to execute the diagram.
Historically, engineers and scientists have utilized time-based block diagram models in numerous scientific areas such as feedback control theory and signal processing to study, design, debug, and refine dynamic systems. Dynamic systems, which are characterized by the fact that their behaviors change over time, are representative of many real-world systems. Time-based block diagram modeling has become particularly attractive over the last few years with the advent of software packages such as Simulink® from the MathWorks, Inc. of Natick, Mass. Other examples of software for modeling includes state-based and flow diagrams, such as those found within Stateflow® from the MathWorks, Inc. of Natick, Mass., data-flow diagrams, and software diagrams, such as those found in the Unified Modeling Language. Such packages provide sophisticated software platforms with a rich suite of support tools that makes the analysis and design of dynamic systems efficient, methodical, and cost-effective.
A common characteristic among these various forms of block diagrams is that they define semantics on how to execute the diagram. Many packages include a code generation capability that converts the block diagrams to executable code that can execute on computational hardware, such as, for example, a computer, microcontroller, field programmable gate arrays (FPGAs), and custom hardware. The executable code can be in the form of a general purpose programming language such as C/C++, assembly code, or a hardware description language.
In present day industrial projects, computer-generated models are being used that have reached a stunning level of complexity in terms of size. For example, tens of thousands of blocks that represent primitive and aggregate mathematical operations may be present.
In order to manage the complexity of such models, partitioning is used to create more or less separate and independent modules (or ‘units’) in the model. This facilitates teams of engineers to work on engineering projects where each engineer (or, possibly again, a team of engineers) is responsible for one unit of the overall model. This paradigm is often a necessity in that the overall system development task has reached a level of complexity that is beyond the cognizance of any one single individual.
Typically, an architectural model is applied that contains a number of more or less independent modules. These modules are developed largely independent of the architecture and so the architecture modelers may be ‘customers’ of the separate design teams responsible for each of the modules.
When a desired architecture has been decided on and specific versions of its included modules have been selected, the overall system needs to be analyzed. This can be done by first using simulation followed by a stage where the implementation as, e.g., generated code for the block diagram is used. Such generated code is used in critical design stages such as rapid prototyping and hardware in the loop simulation.
In general, the overall code-base corresponding to an overall block diagram can become very extensive and heterogeneous as different implementations may be chosen for each of the modules and so may consist of binaries generated from different programming languages or even a mixture of programming languages and hardware synthesis languages such as VHDL. Typically, though, one programming language, such as C/C++, is used across the module design teams.
In large scale modeling projects that rely on automatic code generation, typically a large number of support functions or classes and auxiliary code such as typedefs and global symbols are used in the actual core algorithmic code. For example, to keep cost low, instead of using floating point microprocessors, it may be desired to implement embedded software on fixed point microprocessors. These, however, rely on fixed representations of accuracy with which numerical values are captured. The characteristics of these representations are called their fixed-point datatype. Also, when generating code for fixed point processors, conversion between these types and from floating point to fixed point as well, is required. This conversion process is implemented by fixed point conversion utility functionality.
Automatic code generation can create inefficiencies by automatically generating redundant code. If some type of code sharing is implemented with automatically generating code, difficulties can arise in the management of shared code, such as management of the proper platform for execution of the code, such as operating systems, processors, etc. Also, duplicate names of units of code can cause name conflicts when models are combined, as the names then become ambiguous.